1. Technical Field
The disclosure generally relates to a method for dynamically controlling data paths (of Machine-type-communication (MTC) local access device(s)), which may be applied to MTC networks.
2. Related Art
Machine-type-communication (abbreviated as MTC) or Machine to Machine communications (M2M) can enable information exchange between a subscriber station (or a wireless communication device) and a server in the core network (through a base station) or just between subscriber stations, which may be carried out without any human interaction.
MTC application may use sensor devices that capture certain events such as temperature, and gas or water consumption and then transmit the captured information over a wired network, a wireless network or a hybrid of wired and wireless network to an MTC application (residing at a MTC server). For example, smart meters with metering application could be expected to be one among the early MTC devices deployed. Many other MTC devices such as e-health monitors are envisioned and are expected to be widely used in the near future.
For another example, Third Generation Partnership Project (3GPP) establishes common and specific service requirements including MTC communication scenarios. According to the 3GPP framework, MTC devices may communicate directly with one or more MTC server(s) (which may or may not be controlled by the mobile network operator). In another communication scenario, so-called local-access devices without 3GPP mobile communication capability may be located in a MTC capillary network which provides local connectivity between the local-access devices within its coverage and a MTC gateway device. The MTC gateway device could be a MTC device which acts as a gateway for local-access devices in a MTC capillary network to communicate through a PLMN with one or more MTC server(s).
It may be envisioned that several MTC gateways are interconnected by means of wireless (such as IEEE 802.11 WLAN/Wi-Fi) or wire-line (such as Ethernet (wired LAN) or broadband PLC) technologies. For instance, MTC gateways without any interconnections to other MTC gateways may be considered as single point of failure. If one MTC gateway failed, the whole capillary network would be cut-off from MTC communication with the MTC server. On the other hand, when capillary networks are deployed in an interconnected fashion, hot stand-by mechanism may be in place which would provide improved service quality and potentially higher revenues.
However, it is required to populate IP stack routing tables of the interconnected MTC gateways for the situation that several MTC gateways are interconnected and such interconnection may allow a local-access device use a MTC gateway which does not provide coverage for the area where the local-access device is located. Further, it could also be desirable to have policies in place per service data flow to describe, for instance, that a certain service data flow might use WLAN access during a first scheduled period and evolved universal terrestrial radio access network (E-UTRAN) access during a second scheduled period.
Routing table and policy updates may be statically pre-configured by the mobile network operator (MNO) or dynamically configured by the MNO via the Access Network Discovery and Selection Function (ANDSF), which is a network device specified in 3GPP standard. However, the aforementioned implementations currently have some difficulties especially for the situation that MTC service provider and MNO are different organizational entities.
For the statically pre-configured implementation, the MTC service provider could allow the MNO to access the MTC gateways to pre-configure them accordingly. However, it may not be always desired by the MTC service provider to give the MNO access to its assets. Alternatively, the MTC service provider could request certain information from the MNO to pre-configure the MTC gateways himself. However, it may not be always desired by the MNO to provide this kind information.
As with the statically pre-configuration implementation there are issues also for the dynamic implementation when the MTC service provider and the MNO are different organizational entities. In particular, the MNO is unaware of specific information regarding the MTC gateways. For instance, the MNO may not be aware whether MTC gateways are interconnected or not. Even if the MTC gateways are interconnected, the MNO may not be aware of the interconnection network characteristics (described for instance by bandwidth, latency, jitter, loss, and so forth).
The current state of the art does not address the issue of interconnected MTC gateways, populating routing tables and conduction policy updates of MTC gateways, and does not provide an implementation to enable the ANDSF to perform a task with information from a domain outside of the mobile network operator domain. Therefore, it may be important for the wireless communication industry to research and develop an effective routing implementation for interconnected MTC gateways (and its corresponding capillary network(s)) in a MTC network.